The present invention relates, in general, to improvements in manufacturing planning and, in particular, to a method and system for efficiently processing bill of material and project network data. These improvements are accomplished by refinements in the techniques of low level coding and continuity checking which are integral to automated bill of material processing.
Bill of material processing is used to define product structure which consists of end products, assemblies, subassemblies and component parts. The use of bill of material data in both implementing engineering changes and in material requirements planning is well known. Project networks are used for managing process development, construction and product manufacturing projects.
Low level coding and continuity checking are established techniques for production planning and control. Low level coding is generally used to facilitate the planning of material requirements, from end items down to raw materials and purchased parts. The low-level code for an item in a bill of material indicates the lowest level where the item was used as a component of higher levels of assemblies and subassemblies. Low-level codes (LLC) are used to avoid repeated explosion/implosion of multiple-use sub-assemblies each time they are encountered in the bill of material, thus increasing the efficiency of summarized bill of material retrieval and material requirements planning. A peculiarity of common low-level coding is the reverse order of the numeric value of the code assigned to an item at a particular level when compared to the highest level assembly. While an end item is logically at the highest level in the hierarchy, its low-level code is zero. The lower the level within the hierarchy of a bill of material, the higher is the numeric value of the code.
Continuity checking is a prerequisite for the effective maintenance of manufacturing product structures. It assures the continuity of the related bill of material, i.e., it prevents a part from being accidentally contained in itself. If continuity is violated, a loop is produced, and proper assignment of low-level codes cannot be made.
The techniques of low-level coding and continuity checking can be applied to any problem that can be expressed as a directed graph or network. In a network, the low-level code represents the relative distance between a particular node in a network and one or more end nodes. The relative distance is expressed by the number of edges on the longest directed path from any one node to any end node.
Gaining data processing efficiency through the implementation of summarized logic based on low-level code involves an overhead associated with low-level code maintenance. Any time a new component is added to any assembly bill of material, it is necessary to verify that the component low-level code is numerically greater than the low-level code of the assembly to which the component is to be added. If it isn't, the low-level code of the component is made at least one greater than its higher level assembly. If the component item happens to be another assembly, then all of its components must be similarly verified. The process may need to be repeated recursively until the lowest level raw material or purchased item is reached.
FIG. 1 is a system block diagram showing the components used in other implementations for initial loading of both item and bill of material component data in batch processing and the subsequent on-line updating of the same data using hierarchical data bases. Bill of material processing system 10 contains two control files 20 and 22 that are used during the initial loading as well as during the subsequent updating of data.
In commercially available methods, when updating low-level codes, the original low-level codes are copied into backup control file 22. If a loop is detected, processing is terminated and the original low-level codes are restored. Additionally, some other information is recorded into the explosion control file 20 to keep track of the recursive update process and to detect product structure continuity errors. Thus, low-level code maintenance involves a significant overhead. Commercially available software products implementing low-level coding/continuity checking techniques include IBM Corporation's Data Language/I (DL/I DOS/VS) and Information Management System/Virtual Storage (IMS/VS). Detailed documentation is available in "IBM System/370 Low-level Code/Continuity Check in Data Language/I DOS/VS: Program Reference and Operations Manual", "IMS/VS Low-level Code/Continuity Check In Data Language/I: Program Reference and Operations Manual", and "COPICS Bill of Material/On-line and Batch Utilities II with Repetitive Data Management: User Guide and Reference Manual.+ It should be noted that these products apply only to bill of material processing; low-level code processing techniques have not been previously used for project network processing. There are many software products available for project management. An example is IBM Corporation's Application System product which is described in the publication " Managing Projects with Application System."
New users of a bill of material software product create new item master data 14 and product structure (bill of material component) data 18 either from scratch or by copying data from existing databases using sequential file 12. Any existing low-level codes are initialized to zero and new low-level codes are to be generated and stored in item master records 14. During the initial generation of low-level codes, logic means 16 processes input item master records 14 sequentially. No further processing is required if either the item has no component items in product structure file 18 or the item has a low-level code greater than zero, i.e., this item has already been processed as the component of another item. If processing is required, the item is exploded into its components. If the low-level code of the component is higher than that of the parent item, no low-level code updating is required. Otherwise, the numeric value of the low-level code of the parent item is incremented by one and stored as the new low-level code of its component item. If the component item has sub-components, this process is repeated recursively.
The low-level code updating process performed by logic means 28 is similar to that for initial generation of low-level codes. Each time a new component record is added to the bill of material database 18 by the terminal user 24, the low-level code for the component item must be maintained to ensure that it is numerically higher than the low-level code of its parent item. If not, the low-level code for the component item will have to be updated. If the component item has subcomponents, then the component item has to be exploded and the update process continued recursively until no more updating is required for the subcomponents. When product structure relationships are deleted, it is not necessary to decrement the low-level codes. The use of low-level codes is not affected if lower in the scale, i.e., greater in numeric value than the actual usages in the product structure trees. Decrementing low-level codes require extensive processing of where-used relationships and results in decreased performance.
In the available software products, the explosion sequence (tree walking) is a combination of horizontal (left to right) and vertical (top to bottom) explosions, sometimes called diagonal explosion. This technique is used primarily to avoid unnecessary locking of the entire product structure tree by retrieving every component item with the intent to update it. Instead, parts of the product structure tree are retrieved initially without update intent. Those paths requiring a low-level code updating are then retrieved again in order to update them.
Each item is first exploded one level horizontally and all components at that level are examined. Only those components that require low-level code updating are entered into a list which is maintained in explosion control database 20. Each entry contains an identifier which is composed of a low-level code and the component item key. Each of these selected component records are retrieved a second time and their low-level codes are updated with a value which is one greater than the low level code of the parent item. The new low-level codes are also entered into the control database.
Subsequently, using vertical explosion, the first occurrence of a component key headed by the new low-level code is read back from the control database. This component is then further exploded using horizontal explosion. In this manner, the left most hierarchical path is first exploded vertically. When the processing of the left most path is completed, the traversal is reversed to reach the adjacent parallel path on the right. Since the old path is not traversed again, the previously exploded component reference is removed from the control database.
A prerequisite for the creation and maintenance of bills of material is reliable checking of assembly-to-subassembly continuity. An improper sequence may cause bill of material retrieval for production planning programs to loop, for instance, when a part is contained either directly or indirectly within itself. This error condition is referred to as a continuity error or a bill of material loop. Similar loops can also be encountered by processing unidirectional networks such as project networks.
During low-level code generation and updating, it is essential to perform continuity checks to preserve the integrity of product structure data. Each branch of the product structure tree, originating from the parent item, constitutes a distinct hierarchical path. A hierarchical path is defined by the path from a parent item (root node) to a particular purchased item or raw material (leaf node) within the product structure tree. In a particular hierarchical path, no item must occur twice. As each path is traversed, an entry consisting of the component item identifier (key) is made in a control record in explosion control file 20 for each item encountered while traversing the path from top to bottom. The continuity of the product structure is verified by checking each new entry against all existing entries to detect whether the new entry is a duplicate of an existing entry. If no duplicates are encountered upon reaching the leaf node (a purchased item or a raw material), then the direction of traversal is reversed and the entry is deleted from the control record. The process is then repeated for the adjacent path, proceeding from left to right and then from top to bottom. Thus, at any point in time, only one path or a partial path is recorded in the control record.
While traversing a specific branch of the product structure tree, the traversal is stopped when an existing low-level code for a component item is found to be numerically higher than its parent assembly. The assumption made is that the low-level codes for all lower level components have been previously checked for continuity. When a loop is detected, the update process is terminated and the database is returned to a consistent state with respect to the low-level codes that may have already been updated. Each time a low-level code for an item is updated, a backup copy of the original low-level code is written into the backup control database 22. The entry consists of the item key and the old low-level code. When a continuity error is detected the insertion of the product structure record is terminated and the original low-level codes are recovered from the control database. Low-level codes are updated during the forward pass from top to bottom through a hierarchical path before detection of any continuity error. When an error is detected, the low-level codes must be restored to original values, otherwise product structure continuity will be lost.
It may be noted that database managers log all changes to data and are capable of rolling back all changes made within a logical unit of work. Although it may appear that it is unnecessary to keep copies of original low-level codes in a control database, defining every insertion of a single product structure record as a separate unit of work may involve unacceptable overheads caused by the database commit process. Traditionally, the commit/rollback capabilities of database managers have not been used for restoring low-level codes.
Although at least superficially, there does not appear to be any relationship between bill of material processing and project network processing, similarities do exist and are described more fully below. However, for background information the references cited herein provide well-known descriptions of prior art project network methods.
There are three major variations in project management techniques commonly used in commercially available software: Project Evaluation and Review Technique (PERT), Critical Path Method (CPM), and Precedence Diagramming. The leading text reference for these techniques is "Project Management with CPM, PERT, and Precedence Diagramming," third edition, by Joseph J. Moder, Cecil R. Phillips and Edward W. Davis, Van Nostrand Reinhold Company, Inc., 1983. Traditionally, computer programs for project control have used two dimensional matrices which are presorted in i-j node sequence and stored either in memory or in sequential files. The recent trend has been to store the matrices in relational databases, but the processing logic continues to be sequential in nature. The random access capability of relational databases have not been exploited in project network software.